Interface selection from multiple networks

ABSTRACT

An arrangement is disclosed that enables a mobile device to manage multiple network interfaces in order to be substantially always reachable on the Internet. Wired LAN, Wireless LAN, Wireless PAN and cellular systems are technologies that are employed in the exemplary embodiment described. Scanning of the available network infrastructures is performed by a specific software agent implemented in a mobile device. User mobility profiles, power consumption, cached context information and application requirements are taken into account so that the end user can always communicate through the most appropriate network interface without explicit manual intervention.

The present invention relates to interface selection from multiplenetworks, especially wireless networks, and in particular, but notexclusively, to interface selection by a mobile device from among aplurality of networks, especially wireless networks, that may beperiodically available at least temporarily in a communications system.

Wireless local area networks (WLAN) are becoming popular nowadays, notonly in indoor environments but also in outdoor spaces. By means ofwireless access points, mobile/client devices can use networkingservices without a wired connection in similar fashion to use of a wiredLAN. General information on wireless LAN protocols and systems may befound in “Wireless LANs”, by Jim Geier, Macmillan Technical press, 1999.One problem with WLAN is power consumption, which can become an issuefor portable devices like a personal digital assistant (PDA). WirelessPersonal Area Network (WPAN) technologies like Bluetooth™ can offerwireless network connectivity at a lower bandwidth but withsignificantly reduced power consumption. When neither WLAN nor WPANaccess infrastructure is available, a mobile device would require afunctionality which allows it to use other wireless systems, ifavailable, e.g. outdoor cellular systems like General Purpose PacketRadio System (GPRS) to generate a new connection or possibly to stayconnected with the Internet or with a corporate intranet. If properlyadapted, the same mobile device could be plugged into a wired LAN whenput into its docking station when coming back to office. At this point,the device may well be stationary, but it will be appreciated that itmay still be considered a mobile device in reflection of portability orfacility to change location.

The mobile device should therefore have multiple network interfacesavailable, at least temporarily, that provide connectivity in a varietyof contexts. Such a terminal is described as a multi-mode terminal.These interfaces could be either embedded in the device or can bemanually inserted by the user, as in for example the case of plug-incards. One device of this general type is disclosed in GB-2362237, inwhich a PDA has a base unit with at least a battery holder and a numberof changeable modules which slot, slide or clip into the base unit. Thisprior art arrangement proposes a card module that Implements radiofrequency (RF) circuitry, link control and baseband functions forimplementing wireless links, although there is no disclosure of how aselection could be made or implemented between a plurality of networkinterfaces which might become available for choice from time to time.

To date, in cases where multiple options exist, there is no universalsolution to automatically decide which network interface any particulardevice should use at a particular time. In fact, some chipset and cardmanufacturers are announcing proposals for combination products (“combo'chipsets”) that embed multiple wireless transmission standards and someof these already exist on the market. However, without supportingsoftware, the user must always manually select one network interface toconnect to the Internet or to a corporate Intranet. This is the case formost operating systems like Windows CE and Windows XP as supplied byMicrosoft Inc. USA or Linux.

In order to use a specific wireless interface, a corresponding networkinfrastructure that provides access to a backbone network must bepresent and a discovery procedure for available networks access must beprovided. This discovery process can be time and energy consuming. Evenscanning for all the frequencies of one system is so power consumingthat mobile terminals for cellular systems conventionally do not do thisbut only scan a limited number of frequencies. Scanning for a specificwireless network infrastructure (e.g. WLAN) may result in a list ofusable access points to which the mobile device can connect. In case aWLAN infrastructure (as in the previous example) is not found, the WLANinterface in the mobile device cannot provide network connectivity andanother one has to be investigated.

Depending on the environment in which the user finds himself, it isprobable, especially in the future, that there are multiple networkinfrastructures available, at least temporarily. The prior artarrangements can therefore be seen to be deficient in the automation ofdiscovering whether and which wireless network infrastructures areavailable and in consequently activating the proper network interfaces.This may lead to deficiencies in a mobile device meeting a user'sconnectivity expectations, for example in terms of cost, convenience,power consumption and bandwidth. A user of currently disclosedarrangements may therefore experience difficulty in establishing ormaintaining a location independent connection to a backbone network likethe Internet. This is the case with current arrangements, at leastwithout manual intervention which may be considered as inefficient andgenerally undesirable.

It is an object of the present invention to provide improved networkselection from multiple networks and in particular, but not exclusively,to provide improved interface selection by a mobile device from among aplurality of networks, especially wireless access networks, that may beperiodically available at least temporarily in a communicationsenvironment.

An automatic network interface selection mechanism would providebenefits for the end user in terms of usability. Accordingly, thepresent invention provides a wireless client device for use in anInternet Protocol compatible communications network, said client devicebeing adapted to communicate with said network in accordance with one ofa plurality of communications standards and to make a selection forconnection to said network from among a plurality of network interfaces,said device being arranged in use to make a said selection automaticallyand according to a predetermined network interface selection policyimplemented in said client device. Such a device may be called amulti-mode terminal. A client device may be a user terminal such as amobile terminal.

A said network interface selection policy may be selected forimplementation by user intervention or by said client device itself fromamong a predefined set of said selection policies stored therein.

A said network interface selection policy may include a consideration ofat least one of location or context awareness, preferably including amobility parameter indicative of whether a said location or context isdynamic or static and/or an indication of how such information has beengathered.

Said client device may be adapted to change automatically betweennetwork interface selection policies under predetermined circumstances,authority to make a said change preferably being provided by a userand/or preferably being notified to a user.

Said client device may be adapted to test for the availability of one ormore of said network interfaces, preferably by periodically performing ascan of available interfaces.

Said client device may be adapted to pre-connect to a said interfaceselected by a said network interface selection policy, so as to test theavailability of said interface in advance of performing a handoverthereto from a currently connected interface.

Said network interfaces may be controlled by a multi-standard enabledwireless adaptation layer implemented in an operating system of saidclient device.

A plurality of said interfaces may be assigned a priority forimplementation in a said network interface selection policy, a saidpriority preferably being changeable in said client device and morepreferably being dynamically changeable to reflect current status ofsaid interface.

Said client device may store information relating to access pointscurrently available and/or previously visited.

Said client device may be adapted to monitor network interfaceavailability substantially continuously and preferably keeps updated astored list of available said interfaces.

A switch between said interfaces may be performed by said client devicein the event that a stronger or higher priority interface becomesavailable or in the event that a connection to a network infrastructurethat uses current said interface is lost.

Said client device may be adapted to check, at least periodically, theavailability of one or more access points neighboring a currentlyconnected access point.

A said network interface selection policy may include consideration ofat least one of usage cost, bandwidth availability, received signalstrength, link quality, link availability, signal-to-noise ratio, powerconsumption or user intervention.

A said communications standard may comprise one of Ethernet, IEEE802.11a, IEEE802.11b, Bluetooth™ GPRS and GSM data.

The present invention also provides a method of performing communicationin an Internet Protocol compatible network, the method including:

-   -   a) connecting a client device to said network in accordance with        one of a plurality of communications standards; and    -   b) changing automatically between said communications standards        under predetermined circumstances defined in a network interface        selection policy implemented in said client device.

The present invention also includes a computer program product forexecuting a method described above in accordance with the presentinvention when executed on a computing device. The present inventionalso includes a data carrier having the computer program product encodedthereon as an executable program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system including an arrangement accordingto an embodiment of the present invention;

FIG. 2 is a use case diagram for a network interface selection policyimplemented in a client device of FIG. 1;

FIG. 3 is a class diagram for a network interface selection policyimplemented in a client device of FIG. 1; and

FIG. 4 is a task diagram for a task manager of a network interfaceselection policy implemented in a client device of FIG. 1.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The present invention will now be described with reference to certainembodiments and with reference to the above mentioned drawings. Suchdescription is by way of example only and the invention is not limitedthereto. The term “comprising”, e.g. in the claims, does not excludeother elements or steps and the indefinite article “a” or “an” before anoun does not exclude a plurality of the noun unless specificallystated. With respect to several individual items, e.g. a charneldecoder, channel equalizer, or items given an individual function, e.g.a channel decoding means, channel equalizing means, the inventionincludes within its scope that a plurality of such items may beimplemented in a single item, e.g. in a processor with relevant softwareapplication programs to carry out the function even if these items aredescribed separately.

Where reference is made to a “client device being adapted to communicatewith a network in accordance with one of a plurality of communicationsstandards”, the skilled person will appreciate that such a device may bereferred to as a multi-mode terminal. As a specific example, amulti-mode terminal may have access capabilities for any one ofEthernet, IEEE802.11a, IEEE 802.11b, Bluetooth™, GPRS and GSM.

Where the present invention refers to “standards” used in communicationsarrangements, such a standard may comprise a technical guidelineadvocated by a recognized organization, which may comprise for example agovernmental authority or noncommercial organization such as the IETF,ETSI, ITU or IEEE, although not limited thereto. Standards issued orrecommended by such bodies may be the result of a formal process, basedfor example on specifications drafted by a cooperative group orcommittee after often intensive study of existing methods, approachesand technological trends and developments. A proposed standard may laterbe ratified or approved by a recognized organization and adopted overtime by consensus as products based on the standard become increasinglyprevalent in the market. Such less formal setting of a “standard” mayfurther encompass technical guidelines resulting from implementation ofa product or philosophy developed by a single company or group ofcompanies. This may particularly be the case if, through success orimitation, such guidelines become so widely used that deviation from thenorm causes compatibility problems or limits marketability. The extentto which a piece of hardware conforms to an accepted standard may beconsidered in terms of the extent to which the hardware operates in allrespects like the standard on which it is based or designed against. Inreference to software, compatibility may be considered as the harmonyachieved on a task-orientated level among computer elements andprograms. Software compatibility to a standard may therefore also beconsidered the extent to which programs can work together and sharedata. Such a communications standard may define a wireless accessprotocol, which may be based on any suitable wireless access system,e.g. Frequency Division Multiple Access (FDMA), Code Division MultipleAccess (CDMA), Time Division Multiple Access (TDMA), Time DivisionDuplex (TDD), Orthogonal Frequency Multiple Access (OFDMA) orcombinations of these such as CDMA/FDMA, CDMA/FDMA/TDMA, FDMA/TDMA. As aspecific example, one of IEEE 802.11b, Bluetooth and GPRS may beselected.

Referring to the drawings and for the moment in particular to FIG. 1, acommunications network selection system 10 embedded in a client deviceMT provides a plurality of network interfaces for connectivity to aserver 12 via the Internet or another IP-based network. The clientdevice may be a mobile or fixed terminal providing any of data, fax,video or speech services or combinations of these such as multi-mediaservices, e.g. of varying bandwidth. To achieve this, client devicesinclude multimode ability so as to be able to make best use of thecommunications standards available. In this embodiment, a non-limitedlist of examples used includes an IEEE 802.11b Wireless Local AreaNetwork (WLAN), a Bluetooth™ Wireless Personal Area Network (WPAN) andcellular system in the form of a Generalized Packet Radio System (GPRS).These client devices/nodes may include Personal Digital Assistants(PDA's), laptop computers and mobile phones or similar and, although notnecessarily being moved at any particular time, will be referred toherein for convenience as mobile terminals MT so as to reflect apossibility of portability.

The node through which access to the network is achieved will bereferred to for convenience generically as an access point AP, althoughit will be appreciated that the form of an access point AP will dependon the access technology under consideration. IEEE 802.11b has its ownaccess points AP₁ as does Bluetooth AP₂, whereas the access points AP₃for GPRS may be referred to in the art as base stations BS. TheBluetooth access points AP₂ may connect through a dedicated router 14,while a further router 16 may be provided for WLAN access via the IEEE802.1 b access points AP₁.

The present invention provides an arrangement in which networkinterfaces in a client device may be selected automatically according touser-defined policies whenever a mobile terminal MT has multiple choicesavailable. These policies may take several factors into accountincluding data transfer speed, power consumption, user mobilityprofiles, cached context information, security authorizations andconnection costs.

The user may select one network interface selection policy (NISP) amonga predefined set or define its own new NISP. Once a policy is selected,the mobile device will use the preferred network interface (provided itis available) and will periodically scan for other usable networkinfrastructures. In this way, when the interface with the highestpriority is no longer usable (either because there is no wirelesscoverage or because the user has undocked its mobile terminal or removedthe card), a new network interface is ready to be activated and the userkeeps its network connectivity.

A NISP may be associated with a specific location and context. Themobile terminal (MT) can switch among different NISPs eitherautomatically (for example when a known wireless network infrastructureis recognized and a specific location can be inferred) or by means ofexplicit user intervention. Further details of an NISP and its maincharacteristics are given below.

The diagram depicted in FIG. 2 shows the main use cases for the networkinterface management solution described in the present invention, usingstandard Unified Modeling Language (UML) notation.

The user indicates his/her preferences in the “ConfigureSettings” 100use case: this can be a GUI (graphical user interface) tool where a setof NISPs can be defined and other settings specified as well.“SelectPolicy” 102 activates one specific NISP and it can be invokedeither manually by the user or by a software agent, i.e. NicAgent 104,which is a software daemon that supervises the whole network selectionsystem 10 in the mobile terminal MT. The NicAgent 104 may decide tochange policy, if the user has allowed this behavior in theconfiguration settings of the device. Whenever a policy is changed, theuser may receive a notification through the GUI (“NotifyUser” 106), ifappropriate. Based on the settings defined by the user, which are read(“ReadSettings” 108) upon systems initialization or upon a change in thesettings themselves, the NicAgent 104 periodically probes the availablenetwork interfaces (“ScanInterfaces” 110).

This “ScanInterfaces” 110 use case includes testing the physicalavailability of the network interface, checking its status and verifyingthat it can actually provide connectivity. When a wirelessinfrastructure is found and the policy allows it, the system 10 tries toconnect to it to check if the link is usable and to keep its networkconnections (“Preconnect” 112). This may include, in the example case ofa Bluetooth infrastructure, inquiring for access points AP₂, connectingto them and performing service discovery and authorization procedures,as specified in the Personal Area Network (PAN) profile or in the LANaccess profile.

It should be noted that in this context the Access Point role can alsobe implemented by a mobile phone with Bluetooth and GPRS interfaces(Bluetooth Dial-up Networking profile), or by a Bluetooth enabled laptopthat also has an Ethernet connection.

Based on the outcome of the preconnection case 112 or resulting fromother user's actions (e.g. a network card is physically removed from themobile terminal MT or an Ethernet cable is physically (dis)connected(from)to the MT), some events may be generated (“HandleSystemEvents”114), which are then passed to the NicAgent 104. These events mayinclude:

infrastructure exists and is usable;

infrastructure exists but the mobile terminal MT does not have accessrights;

a new interface card/network cable has been inserted; and

an interface card/network cable has been removed.

The NicAgent 104 reacts to these events according to the policy it isusing at the moment. A possible outcome of these events is theactivation of a new network interface card (“ActivateInterface” 1116),i.e. a handover action is started by “SwitchInterface”. A handover mayinclude deactivating one network interface and activating a new one.Other network layer functions may be involved in this process.

Depending on the event that is generated, useful information can begathered by the NicAgent 104, which may, for example, store it in asuitable memory such as a cache and use it to include context orlocation dependent network selection in the NISP used. The“ManageContextCache” 118 use case refers to the process of managing theinformation related to a specific environment: for example, when a localarea network interface card has been plugged in, e.g. an Ethernet card,and the NicAgent 104 recognizes that the mobile terminal MT has beenconnected to an office network, an “office” context may be inferred.This context may include a description of other network infrastructureslike Wireless LAN and/or Bluetooth that are present in the officeenvironment. Based on this context information, a specific networkinterface selection policy may be activated in the mobile terminal MTand optionally notified to the user (“NotifyUser” 106).

A selection of suitable main classes of an NISP-based mobile terminal MTare shown in the network interface (“if-“) class diagram of FIG. 3. TheNicAgent 104 role is implemented by the IfManager class 200. TheIfManager 200 uses the NetworkInterfaces class 202 and it is associatedwith a Scheduler 204, which is responsible for providing time services,i.e. triggers for checking a specific network interface. TheUserPreferences class 206 keeps all the settings that the user can set.In order to actually control network interfaces, the IfManager 200 usesa Multistandard Wireless Adaptation Layer (MWAL) 208, which is asoftware module that handles all existing software device drivers fornetwork interface cards. The MWAL 208 is linked with the operatingsystem of the mobile terminal MT and it is allows the IfManager 200 tocommunicate with the device drivers of the network interface cards.

On the other hand, the NetworkInterface class 202 is a high-levelrepresentation of the actual wireless or wired network interface card.Its properties include a name (usually operating system OS dependent;“fName”), a type (WLAN, Bluetooth, GPRS or other as the case may be;“fType), a priority (“fPriority”) that can be dynamically changed by theIfManager 200 and flags (“fStatusFlags”) that represent the interfacecurrent status. Other parameters include network layer information(“fL3Info”; default gateway, IP address), the physical characteristic ofthe network interface (whether it is implemented as a removable card“fremoveable: Boolean” or it is embedded in the system) and a list ofreachable access points AP₁₋₃.

The AccessPoint class 210 holds information about the name (“apName”) ofthe access point AP₁₋₃, its type (“apType”), MAC address (“apMAC”),whether it has already been visited or not (“apRegistered: Boolean”), adefault link key (“apLinkKey”) to encrypt traffic and its status(“apStatus”), which is a dynamic parameter that can be set as a resultof infrastructure scanning and previous use of the access point AP₁₋₃ bythe mobile terminal MT. Access Points AP₁₋₃ may be shared by multipleservice providers 212. Information about the back-end network, that theAP gives access to, can be stored as well, e.g. if it is an 10/100 MbpsEthernet or a 44 kbps GPRS connection.

Finally, the Context class 214 keeps information about the environmentsurrounding the user, including a location name (e.g. “office” or“home”) and a list of reachable access points AP₁₋₃. A mobility indexparameter is included to indicate whether the location and/or context isa dynamic one or a static one (e.g. the chance that the user moves awayand enter a new context). A context type indicates how the location orcontext information has been gathered, that is if the location orcontext is defined manually, has been built automatically or has to berefreshed periodically.

The IfManager class 200 represents the actual running application thatmanages all other classes. At the driver's level, the MWAL Module 208performs the unification of the various interfaces as seen by theoperating system, while the IfManager application 200 is responsible forits control.

The IfManager 200 takes care of the wireless interfaces connectivity,management and selection being performed by choosing the best availableinterface according to context and user's preferences. IfManager 200also guarantees that Layer-three connectivity is always maintained byperforming Vertical Handover between the available interfaces whenneeded and consequently updating routing information. It is supposedthat the mobile terminal MT is willing to reach some host in theInternet, hereafter referenced as the server 12.

The IfManager application 200 is in charge of at least the followingtasks:

-   1. Continuous monitoring of network interface availability. Constant    refreshment of the list of available hardware resources and related    properties, which is needed in order to be able to switch interfaces    as soon as a new and/or more preferable interface is added or made    available to the mobile terminal MT or when the currently in use    interface is removed. Hardware monitoring can be performed by    polling periodically for the mobile terminal's hardware status or,    better, by exploiting hardware insertion/removal events.-   2. Access points AP₁₋₃ identification for each available network    interface. Depending on the user's location, surrounding access    points AP₁₋₃ may be known or unknown. Access configuration    parameters of known access points AP₁₋₃ are stored locally in    “context” classes 118 in the mobile terminal MT. Previously unknown    access points parameters may be later discovered and cached for    future use speed up. Depending on the wireless technology, access    point discovery may also be performed on the basis of scanning at    periodic intervals (e.g. a Bluetooth inquiry procedure) or after an    asynchronous event (e.g. IEEE 802.11b WLAN wireless events). For    each interface, a list of detected (reachable) access points is    preferably maintained.-   3. Interfaces connectivity check (“check_interface” function). Each    interface may or may not have Layer-three connectivity, i.e. can or    cannot reach the first router behind the access point AP₁₋₃. In    order to guarantee such connectivity, the interface must have:    -   a) A connectable access point. The mobile terminal's user must        have the rights to connect to one or more access points AP₁₋₃        associated with the interface in question.    -   b) A valid IP address. The infrastructure bearer should provide        via DHCP or other means a valid IP address that allows the        mobile terminal MT to reach the server 12. (These two conditions        a, b have to be checked periodically.)-   4. Mobile terminal MT connectivity check. The mobile terminal's    communication integrity has to be checked periodically. The current    interface the mobile terminal MT is relying on may be removed by the    user, may move out of access point's range, or may change IP subnet.    In all of these cases proper counteractions have to be taken as soon    as the connectivity is broken. Using periodic pings to the first    router behind the access point AP₁₋₃ (default gateway) may check    connectivity integrity; its breakage may be notified by asynchronous    events (hardware removal, wireless events, under-threshold signal to    noise ratio and others). A “ping” procedure tests the network to see    what systems are working. For this purpose one network element sends    out a predetermined signal to another network element and waits for    a response. The correct response indicates that the remote network    element is responding and the network is in tact. A ping procedure    can also test and record the response time of accessing other    network elements. This can provide useful information on which    network elements and/or networks are available and whether these are    overloaded so access times can be optimized. The ping procedure may    use the Internet Control Message Protocol (ICMP).-   5. Vertical handover. Vertical handover may occur in response of two    events:    -   a) A better (according to user preferences) interface that        allows Layer-three connectivity has been detected. The current        interface is left and the new one is attached. This of course        happens only if the new interface guarantees connectivity.        Layer-three Connectivity tests of non-attached interfaces happen        in the background.    -   b) The current interface the mobile node is relying on becomes        suddenly disconnected, either because of hardware removal or        link disconnection or IP subnet change (it may happen that the        mobile node is connected to an access point and roams to another        one that belongs to a different subnet. In this case link        connectivity is not broken thanks to the automatic link layer        handover provided by the bearer, but IP connectivity is).

In case a) the vertical handover is said to be an “upper verticalhandover” and its timings are not crucial since connectivity is notcompromised. In case b) the vertical handover is said a “lower verticalhandover” and its timings are much more crucial since the mobile noderemains in the disconnected state until a new interface or a new accesspoint AP 13 that allow communication re-establishment is detected.

In addition, information retrieved at points 2 and 3 is preferablycached locally in the context database/cache 118, 212 in order torecognize immediately a wireless infrastructures' properties for futureuse.

Referring now in particular to FIG. 4, a task diagram is depicted forthe if Manager 200 and the events will now be discussed in detail.

Wait 300

The wait task 300 is the idle task, the one that spawns all other tasks(the main). It also performs application initialization and resourceallocation when IfManager 200 is started. Wait 300 performs applicationclean up and resource freeing when an application is closed. The waittask 300 also initializes all timers that govern the other task timings.

Hardware Update 310

The hardware update task 310 is awakened each time its polling intervalexpires or when an asynchronous hardware event such as cardinsertion/removal occurs. Its main job is keeping up to date the list ofthe available network cards. Each entry of the list is aNetworkInterface class 202 described above.

As a result of new hardware insertion, the hardware update task 310issues a signal that unlocks the task in charge of checking andrefreshing an interface's access point list (see below). As a result ofhardware removal, the task frees the resources that have been previouslyallocated and, in case the removed hardware is the same the mobileterminal MT used to connect with, the S_DISCONNECTED signal is raised.This signal triggers the “immediate scan” task 320, whose purpose is tore-establish as soon as possible Layer-three connectivity using anotherinterface. In the event that the hardware list remains unchanged, thetask is put asleep again.

Check and Refresh Access Points (APs) 330

This task 330 is responsible for checking the availability ofneighboring access points AP. It does not perform any test on actualconnectivity, neither at Layer-two nor at Layer-three; it just updatesthe access point list of a given interface. If a new access point AP isdetected, a new object “AccessPoint” describing it is added to saidlist; if an access point belonging to the list is no longer available,its entry is freed. The task 330 sorts the access point list by“knowledge”. An access point AP could be “known”, that is the user hasspecified the parameters that are needed to connect to it (e.g.encryption key or encryption method) in a context class. It could be“unknown”, that is it has never been seen before. It could be “cached”,which means that it was previously unknown, but some information hasbeen detected in the past (for example there is/there is not need for anencryption key).

Check and refresh access point task 330 is awaken whenever its pollinterval expires for technologies that do not support wireless eventssuch as Bluetooth, or it can be awaken after a “new access point”wireless event for technologies that support this feature, such asWireless LAN. The check and refresh access point 330 is also awaken by a“new card detected” signal raised by the hardware update task.

Check and refresh access point task 330 raises a signal whenever anaccess point AP is detected on an interface with higher priority thanthe one in use. This signal is then caught by the link and ping task340, which checks whether the new discovered access point AP can be usedto connect to the server 12 or not, as discussed below in greaterdetail. After completing the access point scanning, the check andrefresh access point task 330 returns to sleeping.

Link and Ping 340

The link and ping task 340 is responsible for checking whether aninterface is able to connect to the server 12 via one or more of itsaccess points AP₁₋₃ in the list. It is hence preferably called only forinterfaces whose access point list is not empty. For a given interface,all access points AP₁₋₃ in the list are first checked for link layerconnectivity, then IP configuration is checked by issuing DHCP requests,and pinging the server 12 finally checks network connectivity (forscalability reasons, pinging the first router 14, 16 beyond the accesspoint AP is preferable). The start of each stage implies the successfulcompletion of the previous one. Success or failure of steps is recordedin the field “AP_status” of the related access point object. Theseactions are performed by the function “check_interface”, also used bythe immediate scan task, which is explained later.

The link and ping task 340 is awakened when the poll interval of aninterface having no empty access point list and with higher prioritythan the one currently used expires. This is needed to allow verticalhandovers towards higher priority interfaces. Optionally, it could beawakened for lower priority interfaces, so to enhance handoverperformance whenever a handover towards lower priority interfaces isneeded. The choice of enabling or not the latter depends on userpreferences and context restrictions (power conditions for example).

Once an interface able to offer Level-three connectivity is discoveredand a vertical handover is desirable (i.e. the new interface has higherpriority than the one currently in use), the link and ping task 340raises a signal that awakens the vertical handover task. Thisessentially takes care of the network interface switching. Instead, ifno interesting access points have been discovered, the task returns toan idle state.

The link and ping task 340 is preferably performed on an interfacebasis, which means that its scope is limited to a single interface andnot to all existing interfaces. On the contrary, the immediate scan task(explained next) refers to all available interfaces and is intended forimmediate connectivity recovery.

Immediate Scan 320

The immediate scan task 320 is awakened by the S_DISCONNECTED signal,which is raised by other tasks as soon as the network interface themobile terminal MT is currently using does not provide connectivity tothe server 12 any longer. This could happen for two reasons: 1) thehardware itself becomes unavailable; 2) either the link layer or thenetwork layer connectivity breaks. In the first case, the task 320 isawakened by the hardware update task. In the second case it is awakenedby the ping current interface task 350. Immediate scan 320 first checksfor available access points AP on the same interface the mobile terminalMT was connected with, as the disconnection could only be a matter of IPsubnet roaming and a simple DCHP request will do. If connectivity is notrestored, immediate scan 320 checks for connectivity using lowerpriority interfaces. If a connected interface is found, immediate scan320 awakens the vertical handover task and interface switch then occurs.On the contrary, if no interfaces are able to provide connectivity, thetask 320 eventually ends up in a “no connectivity” alert and turns backto an idle state.

Ping Current Interface 350

This task 350 is responsible for current network interface failuredetection, both at the link and the network layer. It regularly probesthe server 12 with a ping request and it raises a S_DISCONNECTED signalas soon as the current interface does not provide Layer-threeconnectivity any longer. If the server 12 is reachable, this task 350turns back to an idle state.

Vertical Handover (VH) 360

The vertical handover task 360 is awakened when a vertical handover isneeded and a suitable successor interface has already been detected bythe link and ping task 340 or the immediate scan task 320. The VH 360takes care of interface switching and IP parameter inheritance. The task360 makes the new interface operational and communicates the event toprocesses that may be interested in it. After vertical handovercompletion, it turns back to an idle state.

Both “link and ping” and “immediate scan” tasks make use of the“check_interface” function, which is now explained in detail. Its roleis to check layer two and layer three connectivity of a given interface.All access points AP belonging to the selected interface are firstchecked for layer two connectivity, and proper flags are set accordinglyin the objects that describe each analyzed access point (linkavailable/not available). If an access point AP₁₋₃ is found to providelink layer connectivity, IP connectivity is then checked. First, a DHCPrequest is made over the interface in order to gain a valid IP addressfrom the bearer's infrastructure. If no IP address is given, the accesspoint AP₁₋₃ is not suitable for communication. On the contrary, if an IPaddress is given, the last stage begins. This involves checking IPconnectivity by pinging the server 12 and waiting for a response. If noresponse is given within a preset timeout, the access point AP₁₋₃ is notsuitable for connection, otherwise the entire interface is said to beconnected and marked as such. In this case the function exitssuccessfully. If one of the described stages (link connection, DHCPrequest and pinging) fails, the function repeats the procedure for thenext access point AP₁₋₃ in the list. If the list is completely scannedand no suitable access point AP₁₋₃ has been found, the interface is saidto be disconnected and the function exits unsuccessfully.

At each, stage success or failure for a given access point AP₁₋₃ isrecorded and cached so to speed up future scans by querying first theaccess points AP₁₋₃ with the higher number of successful stages. Infact, before scanning begins, the access point list AP₁₋₃ is sorted bydegree of knowledge and by number of previously succeeded stages. Firstare placed registered access point points AP₁₋₃ with three succeededstages, then cached access points AP with three succeeded stages. Then,all registered access points AP are sorted by number of succeeded stagesand eventually all access points AP₁₋₃ are so cached.

It may also be the case that if some cached access point AP₁₋₃ retains apredetermined number of succeeded stages, e.g. less than three for adefined number of calls, its scanning will not be performed any more andit will be marked as “unavailable” for future scans. The same thingpreferably happens to access points AP₁₋₃ that have explicitly rejectedconnection attempts.

-   -   The check_interface function has the following prototype:    -   Int check_interface(struct NetworkInterface* nic, int mode);    -   Its arguments are a pointer to a “NetworkInterface” class and a        “mode”.        The “NetworkInterface” (see FIG. 3, 202) class contains the        description of a single network interface, while the mode        indicates whether the function has to check for all available        access points AP₁₋₃ associated with the interface or has to exit        as soon as a usable access point AP₁₋₃ has been found. The first        mode is used by the “link and ping task” 340, the second mode is        used by the “immediate scan” task 320, where the crucial thing        is finding out immediately a usable access point AP₁₋₃.

Embodiments

The invention is particularly relevant to devices/nodes which are oftenmoveable, hence referred to herein generically for convenience as mobileterminals MT, and that are equipped with two or more network interfaces.This includes portable computers, handheld devices and high-levelcellular phones. The solution is intended to run at the mobile terminalMT only, and no assumptions are made on the bearers' infrastructureswith exception of the requirement for ordinary networkauto-configuration services (DHCP, BOOTP, PPP and similar). Possiblefields of utilization include office environments. The proposed solutionautomatically switches between the wired Local Area Network and theWireless domain when the user undocks his/her laptop for example.Methods of the present invention may be implemented in software andexecuted on a computing device, e.g. a portable computer, a handhelddevices such as a PDA or a cellular phone which includes a digitalcomputing device such as a microprocessor, an ASIC having computingfunctionality or a programmable digital logic element such as aprogrammable gate array, a Programmable Logic Array (PLA), aProgrammable Array Logic (PAL) or a Field Programmable Gate Array(FPGA). Such software may be supplied in the form of a computer programin executable form stored on a data carrier such as a CD-ROM, adiskette, magnetic tape as well known to the skilled person.

With regard to mobile environments, the present invention can maintainconnectivity when the user moves between different contexts. Forexample, connectivity is not dropped when the user exits his/her home oroffice wireless local area network by attaching to a cellular bearer.

The present invention solves the problems of manual network scan, choiceand configuration. Available network interfaces are automaticallysorted, e.g. in order of user's preferences, which could take intoaccount bandwidth, costs and power consumption. In any case, given theprofile of usage, the software will automatically decide on the bestavailable interface.

The present invention falls in the middleware field of wirelessconnectivity, which is an area that will play an increasingly importantrole in the future. Among further differentces and advantages of thepresent invention is the provision of context awareness in the processof wireless network scanning and consequent network interface selectionin a mobile terminal MT.

While the present invention has been particularly shown and describedwith respect to a preferred embodiment, it will be understood by thoseskilled in the art that changes in form and detail may be made withoutdeparting from the scope and spirit of the invention.

Glossary

-   -   Access Point: a device that provides wireless connectivity to a        backbone. It could be either a layer 2 device (bridge) or a        network layer device (access router).    -   Bridge: a device that forwards frames at layer two.    -   Router: a device capable of computing routes and forward packets        at the network layer.    -   DHCP: Dynamic Host Configuration Protocol. An IETF standard        protocol that configures automatically IP and DNS parameters of        a host that connects to an IP network.    -   BOOTP: Boot Protocol. Provides DHCP similar facilities.    -   PPP: Point to Point Protocol. An IETF standard protocol that        provides communication between two hosts over a serial line. It        also offers IP parameters auto configuration.

1) A wireless client device for use in an Internet Protocol (IP)compatible communications network, said client device (MT) being adaptedto communicate with said network in accordance with one of a pluralityof communications standards (BT, IEEE802.11, GPRS) and to make aselection for connection to said network from among a plurality ofnetwork interfaces (AP₁₋₃), said device (MT) being arranged in use tomake a said selection automatically and according to a predeterminednetwork interface selection policy (NISP) implemented in said clientdevice. 2) A client device according to claim 1, wherein a said networkinterface selection policy (NISP) is selected for implementation by userintervention or by said client device (MT) itself from among apredefined set of said selection policies stored therein. 3) A clientdevice (MT) according to claim 1, wherein a said network interfaceselection policy (NISP) includes a consideration of at least one oflocation or context awareness, preferably including a mobility parameterindicative of whether a said location or context is dynamic or staticand/or an indication of how such information has been gathered. 4) Aclient device according to claim 1, wherein said client device (MT) isadapted to change automatically between network interface selectionpolicies (NISP) under predetermined circumstances, authority to make asaid change preferably being provided by a user and/or preferably beingnotified to a user. 5) A client device according to claim 1, whereinsaid client device (MT) is adapted to test for the availability of oneor more of said network interfaces (AP₁₋₃), preferably by periodicallyperforming a scan of available interfaces. 6) A client device accordingto claim 1, wherein said client device (MT) is adapted to pre-connect toa said interface (AP₁₋₃) selected by a said network interface selectionpolicy (NISP), so as to test the availability of said interface inadvance of performing a handover thereto from a currently connectedinterface (AP₁₋₃). 7) A client device according to claim 1, wherein saidnetwork interfaces are controlled by a multi-standard enabled wirelessadaptation layer (M-WAL) implemented in an operating system of saidclient device (MT). 8) A client device according to claim 1, wherein aplurality of said interfaces (AP₁₋₃) are assigned a priority forimplementation in a said network interface selection policy (NISP), asaid priority preferably being changeable in said client device (MT) andmore preferably being dynamically changeable to reflect current statusof said interface. 9) A client device according to claim 1, wherein saidclient device (MT) stores information relating to access points (AP₁₋₃)currently available and/or previously visited. 10) A client deviceaccording to claim 1, wherein said client device (MT) is adapted tomonitor network interface (AP₁₋₃) availability substantiallycontinuously and preferably keeps updated a stored list of availablesaid interfaces. 11) A client device according to claim 1, wherein aswitch between said interfaces (AP₁₋₃) is performed by said clientdevice (MT) in the event that a stronger or higher priority interfacebecomes available or in the event that a connection to a network (BT,IEEE802.11, GPRS) that uses a current said interface (AP₁₋₃) is lost.12) A client device according to claim 1, wherein said client device(MT) is adapted to check, at least periodically, the availability of oneor more access points (AP₁₋₃) neighboring a currently connected accesspoint (AP₁₋₃). 13) A client device according to claim 1, wherein a saidnetwork interface selection policy (NISP) includes consideration of atleast one of usage cost, bandwidth availability, received signalstrength, link quality, link availability, signal-to-noise ratio, powerconsumption or user intervention. 14) A client device according to claim1, wherein a said communications standard comprises one of Ethernet,IEEE802.11a, IEEE802.11b, Bluetooth™, GPRS, and GSM. 15) A method ofperforming communication in an Internet Protocol (IP) compatiblenetwork, the method including: a) connecting a client device (MT) tosaid network in accordance with one of a plurality of communicationsstandards (BT, IEEE802.11, GPRS); and b) changing automatically betweensaid communications standards under predetermined circumstances definedin a network interface selection policy (NISP) implemented in saidclient device. 16) A computer program product for executing a methodaccording to claim 15 when executed on a computing device. 17) A datacarrier having the computer program product of claim 16 encoded thereonas an executable program.